Adding Libxc support #521

Tirtho13 · 2025-11-05T13:12:55Z

Libxc interface in mrchem

This is a detailed list of things to do in the integration of Libxc into MRChem. The checklist should have all the necessary changes to complete the integration process.

This is the checklist of all the necessary changes.
NOTE: Please refrain from making commits to the checklists before the changes are made public for review. For owning a particular job, note your name at the end of the specified job. If you want to make a note, add it to the dev notes.

CMAKE files

Fix autocmake for libxc, currently hard coded paths in Factory.h and Functional.h. (Tirthonkor)
Works, but very slow --> needs optimizing (check compile flags?)
Update: currently not working anymore
Udate: working fine, but still have to make final edits

Runtime backend

Simultaneous support for XCFun and Libxc backends: the choice should be made at runtime based on user input, which backend to use, xcfun or libxc. (Ylva)
Can be decided with the keyword DFT { xc_library = libxc }, default is xcfun.

Libxc input

Human readable Libxc input: pass in keyword strings like GGA_X_PBE and parse them with xc_functional_get_number() to get the numerical ID (you can still trivially also support integer IDs) (Ylva)
I think this is done? Code needs expanded list of functionals, but as it is now, the functional name is eg. "slaterx" or "beckex" from mrchem/xcfun which gets translated (manually) to corresponding libxc functionals, "XC_LDA_X" etc.
Susi implemented this

Density threshold

Printing out the functional's density threshold since that will be really important for high precision calculations (Ylva)

To do during/after restructuring (to avoid doing it twice)

Making functionals class abstract and create new classes for libxc/xcfun inheriting from functionals.
Ylva will make a rough separation of classes and then we can update a to do list of which parts that should be done (a lot of the functional class functions are using xcfun and should be made general, but that can be done function by function).

Libxc and functional citation

Proper printout of the Libxc citation information; both for Libxc itself (xc_version(), xc_reference(), xc_reference_doi()) and the used functionals (see Libxc manual for examples) (Ylva) (Tirthonkor)
Prints citation for libxc, not yet for the used functional
Should use libxc function to automatically get correct citation
Citations for individual functionals added

Get hyb parameters from libxc

Checking that hybrid parameters are parsed from Libxc, not hard-coded in MRChem
Done

Overwrite Libxc functional settings

Support for overwriting Libxc functional settings; this requires defining parameter arrays for each functional used in the calculation and calling xc_func_set_ext_params for each of them before the functional is used (the parameters can change e.g. the fraction of exact exchange) (Tirthonkor)
This can be done in a later pull; there remains too much to be done

Testing

Make current xcfun-based unit tests work
Make current xcfun-based regression tests work
Make new libxc-based unit tests
Make new libxc-based regression tests

Documentation

User manual with some input examples
Programmer's manual outlining how the interfacing of the two libraries has been designed and implemented

Added the LibXC integration files.

ilfreddy · 2026-02-02T14:09:06Z

@susilehtola @Tirtho13. Are you satisfied with the LibXC tests which you have now included in MRChem? Could we consider ticking those two off as well?
After that I believe this PR is ready to be reviewed IMO.

susilehtola · 2026-02-02T15:04:46Z

src/mrdft/Factory.cpp

        coefs = {1.0};
        return;
-    } else if (name == "SVWN5") {
+    } else if (name == "SVWN5" || name == "LDA") {


LDA is a bad keyword.

susilehtola · 2026-02-02T15:05:55Z

src/mrdft/Functional.cpp

-/** @brief Run a collection of grid points through Libxc or XCFun
- *
- * Each row corresponds to one grid point.
- *
- * param[in] inp_data Matrix of input values
- * param[out] out_data Matrix of output values
- */


why was the comment removed?

The policy in MRChem is to include this documentation in the header files and no longer in the implementation files. This is why that has been removed. Same for all the other ones.

susilehtola · 2026-02-02T15:06:04Z

src/mrdft/Functional.cpp

- * efficient to have the two consecutive points in two consecutive adresses in memory
- *
- * param[in] inp_data Matrix of input values
- * param[out] out_data Matrix of output values


susilehtola · 2026-02-02T15:06:11Z

src/mrdft/Functional.cpp

-/** @brief Run a collection of grid points through Libxc or XCFun
- *
- * Each row corresponds to one grid point.
- *
- * param[in] inp_data Matrix of input values
- * param[out] out_data Matrix of output values
- */


susilehtola · 2026-02-02T15:06:19Z

src/mrdft/Functional.cpp

-/** @brief Contract a collection of grid points
- *
- * Each row corresponds to one grid point.
- *
- * param[in] xc_data Matrix of functional partial derivative values
- * param[in] d_data Matrix of density input values
- * param[out] out_data Matrix of contracted output values
- */


susilehtola · 2026-02-02T15:06:28Z

src/mrdft/Functional.cpp

-/** @brief Contract a collection of grid points
- *
- * Each column corresponds to one set of grid points.
- *
- * param[in] xc_data Matrix of functional partial derivative values
- * param[in] d_data Matrix of density input values
- * param[out] out_data Matrix of contracted output values
- */


susilehtola · 2026-02-02T15:06:40Z

src/mrdft/Functional.cpp

-
-/** @brief  Evaluates XC functional and derivatives for a given NodeIndex
- *
- * The electronic densities (total/alpha/beta) are given as input.
- * The values of the zero order densities and their gradient are sent to xcfun.
- * The output of xcfun must then be combined ("contract") with the gradients
- * of the higher order densities.
- *
- * XCFunctional output (with k=1 and explicit derivatives):
- *
- * LDA: \f$ \left(F_{xc}, \frac{\partial F_{xc}}{\partial \rho}\right) \f$
- *
- * GGA: \f$ \left(F_{xc},
- *  \frac{\partial F_{xc}}{\partial \rho},
- *  \frac{\partial F_{xc}}{\partial \rho_x},
- *  \frac{\partial F_{xc}}{\partial \rho_y},
- *  \frac{\partial F_{xc}}{\partial \rho_z}\right) \f$
- *
- * Spin LDA: \f$ \left(F_{xc}, \frac{\partial F_{xc}}{\partial \rho^\alpha},
- *  \frac{\partial F_{xc}}{\partial \rho^\beta}\right) \f$
- *
- * Spin GGA: \f$ \left(F_{xc},
- *  \frac{\partial F_{xc}}{\partial \rho^\alpha},
- *  \frac{\partial F_{xc}}{\partial \rho^\beta},
- *  \frac{\partial F_{xc}}{\partial \rho_x^\alpha},
- *  \frac{\partial F_{xc}}{\partial \rho_y^\alpha},
- *  \frac{\partial F_{xc}}{\partial \rho_z^\alpha},
- *  \frac{\partial F_{xc}}{\partial \rho_x^\beta},
- *  \frac{\partial F_{xc}}{\partial \rho_y^\beta},
- *  \frac{\partial F_{xc}}{\partial \rho_z^\beta}
- *  \right) \f$
- *
- * XCFunctional output (with k=1 and gamma-type derivatives):
- *
- * GGA: \f$ \left(F_{xc},
- *  \frac{\partial F_{xc}}{\partial \rho},
- *  \frac{\partial F_{xc}}{\partial \gamma} \f$
- *
- * Spin GGA: \f$ \left(F_{xc},
- *  \frac{\partial F_{xc}}{\partial \rho^\alpha},
- *  \frac{\partial F_{xc}}{\partial \rho^\beta },
- *  \frac{\partial F_{xc}}{\partial \gamma^{\alpha \alpha}},
- *  \frac{\partial F_{xc}}{\partial \gamma^{\alpha \beta }},
- *  \frac{\partial F_{xc}}{\partial \gamma^{\beta  \beta }}
- *  \right) \f$
- *
- * param[in] inp Input values
- * param[out] xcNodes Output values
- *
- */


susilehtola · 2026-02-02T15:08:22Z

src/mrdft/Factory.cpp

        coefs = {1.0, 1.0};
        return;
+    } else if (name == "B3LYP") {
+        ids = {XC_HYB_GGA_XC_B3LYP5};


this is not B3LYP!!!

susilehtola · 2026-02-02T15:08:32Z

src/mrdft/Factory.cpp

        coefs = {1.0, 1.0};
        return;
+    } else if (name == "B3LYP") {
+        ids = {XC_HYB_GGA_XC_B3LYP5};


Suggested change

ids = {XC_HYB_GGA_XC_B3LYP5};

ids = {XC_HYB_GGA_XC_B3LYP};

Here we need to agree on what kind of "behavior" we want the code to have. Ideally a given functional keyword (let's take B3LYP as an example) should yield the same result regardless of the dft library used. Now it is a bit unfortunate that what libxc and xcfun define as vanilla B3LYP is not the same functional (same for e.g. PBE)
Given that libxc is by far more distributed, I would say we should follow the libxc convention and have some translation mechanism in place for xcfun. The drawback from my point of view is that this will break compatibility with previous results. But I guess we need to live with that.

susilehtola · 2026-02-02T15:09:37Z

tests/h2_scf_lda_libxc/h2.inp

+}
+
+WaveFunction {
+  method = LDA                   # Wave function method (HF or DFT)


"LDA" is ambigous, unless it is exchange-only. Use a proper functional.

LDA had become a (psudo) standard alias for SVWN5 which mrchem (and orca, pyscf, etc) use, this pr should not be the one to change this.

Where?

Orca lists

HFS # Hartree-Fock Slater (Slater exchange only) LSD # Local spin density (VWN-5A form) VWN5 # Local spin density (VWN-5) VWN3 # Local spin density (VWN-3) PWLDA # Local spin density (PW-LDA)

There is no "LDA".

PySCF with LDA gives

XC functionals = lda P. A. M. Dirac., Math. Proc. Cambridge Philos. Soc. 26, 376 (1930) F. Bloch., Z. Phys. 57, 545 (1929)

which is just the exchange functional, like I said above.

Looking in the orca manual (6.1.1) can be a bit misleading, as they only specify VWN5:

But running a simple LDA input file shows it is running SVWN5

OK so Orca has documented this in the 6.1 manual; I looked at the 6.0 manual that does not have an LDA keyword.

But in PySCF LDA means something else.

There is no generally accepted meaning, which is why it should not be a keyword.

I don’t mind changing the keyword in the new tests, but there are other tests that use “lda”, and I don’t think it’s a good idea to remove the possibility of calling «lda» for svwn5 in mrchem as people might expect that to work (at least not in this pr)

ylvao · 2026-02-03T16:00:17Z

Personally, I think we have a mergeable code now. It can run libxc on input demand, we have tests, the numbers are consistent and there is otherwise little change to the program, which was the goal here. There are still things to do on the libxc/dft side of the program, eg. restructuring the functional classes, fixing b3lyp, ... which can be done at a later point (it would also be good to not have too much happening in this pr considering that the commits will be smashed).

Unless there is any specific comments, I suggest we wait for the pr to be reviewed :)

ylvao and others added 30 commits January 23, 2025 11:03

mrchem recognize precompiled libxc

28c9d2d

git ignore install folder

b3a4051

cleaned some stuff

240bfbc

newest changes - still not working

f55cd6e

works if imported loc is specified

1068d45

libxc seems to liked with mrchem

16fcdb5

some formatting

86557f7

Libxc is callable from mrchem

0c91c62

Small changes for testing

a49fae4

removed -flto flag for testing

88a6ada

should build libxc

6e84c21

xc.h is found

cccb8c5

changes to factory for libxc

e2a5991

Added the LibXC integration files.

17625a0

Merge pull request #1 from Tirtho13/libxc-mrchem

c86e39e

Added the LibXC integration files.

Added new factory files for libxc

9eeb97b

working on debugg (does not compile)

4ffc3a5

Debugging libxc interface files

98e9e16

some typos

2c45b7c

almost compiling ig

11c7ada

Merge branch 'MRChemSoft:master' into libxc-mrchem

b52aa64

compiles

809136f

restructure new folder for libxc

4d478dd

some cleanup in manes and stuff

2e4e986

change in header inclusion

1ebdc34

functional.cpp file back to original

07c7b23

compiles with external libxc

70075f0

Original mrchem

412a04e

bugs, compiles

2c34c3c

Shit runs but wrong number

20f9d2f

ylvao added 6 commits February 2, 2026 13:17

remove white line

4208f03

accidentaly removed mra variable

e035266

requirement for eigen 3.4.0

ab04812

cmake looks for eigen 3.4 not 3.4.0

34cea32

added linbreak in functional ref print

bdf5dbf

remove comment

8dd14a3

ylvao added 2 commits February 2, 2026 15:24

makes libxc dir in install/include

cdd0549

update doc

41e8b4c

susilehtola reviewed Feb 2, 2026

View reviewed changes

susilehtola and others added 4 commits February 2, 2026 17:11

LDA is not SVWN5. B3LYP is not B3LYP5.

bfb8956

Use SVWN5 instead of ambiguous "LDA"

3644308

Merge branch 'master' into libxc

6cc3e92

Fix formatting issue in helpers.py

457aa2b

ylvao removed the WIP Work in progress label Feb 2, 2026

susilehtola and others added 3 commits February 2, 2026 19:27

Eliminate unitialized variable warning

ccea3bd

testkeyword lda -> svwn5 for libxc tests

5a07ca2

for now use b3lyp5 from libxc as b3lyp

b4bfcd7

ylvao linked an issue Feb 3, 2026 that may be closed by this pull request

Libxc interface? #472

Open

remove unused includes and debug prints

75da7b8

Adding Libxc support #521

Are you sure you want to change the base?

Adding Libxc support #521

Uh oh!

Conversation

Tirtho13 commented Nov 5, 2025 • edited by ylvao Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Libxc interface in mrchem

CMAKE files

Runtime backend

Libxc input

Density threshold

To do during/after restructuring (to avoid doing it twice)

Libxc and functional citation

Get hyb parameters from libxc

Overwrite Libxc functional settings

Testing

Documentation

Uh oh!

ilfreddy commented Feb 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

susilehtola Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ylvao commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Tirtho13 commented Nov 5, 2025 •

edited by ylvao

Loading

susilehtola Feb 2, 2026 •

edited

Loading